This is something I've been working on here and there for a while, but the jam was finally an excuse to finish it. It's a simple space invaders clone in a single tweet. There's no enemy fire or shields, but the invaders do speed up as you destroy more of them, and it's tricky to take the last few out.;)
Version 1.1 - new enemy wave begins when current wave is destroyed
2 comments
Version 1.1 -- Updated for TweetTweetJam5, added square brush feature and tweaked appearance
This is a fully-functional painting program with image save capability in just 277 characters. It's built entirely around mouse controls, and requires a mouse with a scroll wheel for full functionality. Hope somebody enjoys playing around with it.
Controls:
Left mouse button ---- Paint
Right mouse button --- Select paint color (hold and move mouse L/R)
Middle Mouse button -- Save drawing to cart
Scroll wheel --------- Change paintbrush size
X key (hold) --------- Use square brush
This is a compact and efficient system that enables recoloring of sprite graphics. For just 76 tokens, plus any function calls and data strings, you can easily change the color palettes of level tiles or characters based on an arbitrary number of conditions, and even animate them using color cycling. These kinds of techniques were used extensively in games for consoles like the NES to increase graphical variety while conserving memory space. The cart explains the syntax of the data strings and includes a simple demo of what the system can do.
This is a little exercise in code optimization, a fully-functional analog clock in just 196 characters. I'm thinking I might add some features in the future while still keeping it under the 280-character limit, but for now it works just fine.
This is a demo for a way to store console-size game worlds on a Pico-8 cart, which later became my PicoMap system. It contains every level and sublevel map from the original Super Mario Bros., and you can run and jump through all of them. There's no level progression, sound, or things to interact with besides platforms, but the map data includes placeholders for enemy spawn points and interactive objects, just uncomment a line in the init() function to make these visible. I'm not planning to release the finished game, as I don't want it to be taken down for copyright reasons, but I wanted to show some definitive proof that large-scale games are possible on Pico-8.
Controls:
L/R-------Move
Z---------Run
X---------Jump
Up/down---Select Level
Up+down---Restart Level
Cart Technical Info:
- Uses standard sprite flags for map interaction
- 60fps w/ CPU usage between 11-25%
- 1352 tokens, including streamlined platformer engine and graphics/map decompression systems
- 35% of compressed storage limit
- All maps contained in 3.9KB of binary data in map area
- No data stored in the 8KB spritesheet
The big thing is the last point on the list. Instead of storing the nearly-incompressible level data in strings, I instead store the spritesheet in a string because it compresses over 2:1, leaving a full 12KB of potential level storage space. This means that while leaving the majority of compressed data capacity and token count unused, 3 copies of every Super Mario Bros. level could fit on the cart! By my estimates, This should be more than enough to store the worlds of many NES-era games, with space left over for the extra graphics and sound assets. For example, all the level maps from the original Mega Man fit in less than 6KB.
This demo was built entirely in Pico-8, using an early version of my PicoMap system, the latest version of which you can find here: https://www.lexaloffle.com/bbs/?tid=42848
Version 2.0 --New system with much-improved ease-of-use and flexibility in one tiny, 74-token function!
With Pico-8's small spritesheet, many game makers who want a nice title screen are forced to either give up valuable sprite space for a custom-drawn logo, or use a tiny one and zoom in so it but looks very pixelated. Occasionally, someone will use a more advanced method to store images, such as Zep's PX9 or dw817's compression programs. These work well, but the minimum cost of 1000+ characters and 280+ tokens for decompression plus prite sheet rewriting, and/or screen-filling compressed strings can be overkill for many projects, so I came up with my own alternatives.
Version 1.0 encodes logos as 1bpp images into 7 bit-per-character strings, then renders graphical features such as shadows, color gradients, and outlines in real time, without using the sprite sheet. A logo drawing function built with it takes between 85-130 tokens and achieves high levels of compression, though it's limited only to logos, and large ones with outlines can use ~50% of cpu cycles at 30fps.
Version 2.0 uses a version of Run-Length-Encoding (RLE) to compress full-color graphics into strings. It's based on this system here, originally devised by @spellcaster, but I was able to shrink the core functionality down to a fraction of the size and token count while adding a few new features. Like version 1.0 it doesn't use the sprite sheet at all and can handle images of any pixel dimensions. It offers a slightly less compact data footprint, but is far simpler to use, uses less CPU, and can handle any kind of graphics you want. There are 3 versions:
- Core version --the one demonstrated in the cart (74 tokens)
- Version with pre-conversion of strings to tables (104 tokens, lowers CPU usage about 40% further on average --could be useful for 60fps games)
- Version with pre-conversion and real-time vertical and horizontal flipping (161 tokens)
Both 1.0 and 2.0 include instructions to encode your own logos or images, but version 2.0 is much simpler to use, just import or paste an image into the top left corner of the spritesheet, specify its size in pixels, run the cartridge, and follow the icons to encode the image and output a compressed string.
Lately I've heard bits here and there about a new function called unpack that seems to have some significant benefits, but after searching the BBS, the Pico 8 Wiki, and Google, I've barely been able to come up with any solid infomation on it or how to use it.
If someone could point me in the right direction, I'd much appreciate it.
Yes, this is yet another version of Space Invaders, but with this one I'm going for a direct port of the original arcade game. It's mostly complete, with functional gameplay and a working high score save system, but it needs some gameplay tweaks and a few graphical elements, and the sound effects are very much unfinished (I'm working on a version of the 4-tone march using subtones, but haven't ironed out the glitches yet). Anyway, in addition to going for authenticity, I also tried to code this very efficiently, and the whole game (including all graphics and sound), takes under 3KB and only about 1100 tokens.
Any constructive criticism and general feedback is welcome, thanks.
Controls:
L/R------Move cannon
X--------Fire
Version History
Join Squirt as he jumps and bounces in the sky through varying times of day, on his way to Cloud Land.
Controls:
Left/Right--------------Move
Hold Z------------------Small bounce
Hold X------------------Regular bounce
Hold Z+X---------------Super bounce
This is the full version of my single-tweet platformer. It's essentially the same game, but has a lot of important features added, including:
- Animated title screen
- Checkpoints
- Control tutorials
- An improved ending (the original was by necessity super abrupt)
- Birds!
- Parallax scrolling (kinda)
There's no sound or music, and no enemies, but overall I'm pretty happy with how much of a full game I managed to fit in a little over half a Kilobyte. Hope you enjoy it!
Version 1.1: Fixed game over glitch that could occur when pieces were rotated the moment they appeared, pieces can now be rotated clockwise and counterclockwise.
This is a fully playable version of Tetris in fewer characters than a moderate-length email, including:
- Line removal
- Level progression (speed increases after every 10 lines cleared)
- 'Lines cleared' display
- CW and CCW piece rotation
- Soft drop button (with slight delay when next piece appears)
Controls:
L/R-------move piece
Down------soft drop
X-------rotate piece clockwise
O-------rotate piece counterclockwise
Fitting everything in this small a space was pretty tough. I had to cut a few corners, like leaving out the next piece preview, as well as logic to allow movement of blocks once they land, so overhangs are a nuisance. With all that said, though, I worked hard trying to make this an actually decent version of tetris and not just a technical curiousity, so hopefully somebody actually enjoys playing it instead of just staring at the indecipherable souce code. Shoutout to 2dArray, whose Tweetjam Tetris and its genius piece indexing system I built on for this project.
Version 0.2 - Now has definite fail state with timer stop, and recolored graphics
Avalanche!
You are a ground-based defense drone at a top-secret research base inexplicably located by a mountain prone to avalanches. When a tidal wave of snow and ice rushes toward you, you must use your cannon to vaporize it, keeping it at bay for as long as possible so the base staff can get to safety. How long can you hold out?
Controls:
L/R------Move drone
X--------Fire cannon
This is the unintended result of trying to cram a minimalistic space invaders clone into 280 characters. I couldn't figure out how to fit code for individual enemies, but an advancing amorphous mass was just doable. Hopefully it turned out alright on its own terms, and I welcome any feedback or criticism. Warning, though, this can get a bit nerve-wracking. o_O
After discussing base64 encoding in a recent thread, I decided to try my own version of it for storing level strings, but after some experimentation I started wondering how much of a storage benefit it really offers vs. hexidecimal. I also came across an old post from user Overkill from 2016, in which he concludes that unfavorable interaction with Pico-8's built-in compression basically negates base64's byte-per-character advantage.
https://www.lexaloffle.com/bbs/?tid=3738
I decided to perform a test of my own to measure the difference precisely. To do this, I used some web-based tools to generate random strings, using both hexidecimal and my own base64 character set, which uses as many 1-byte characters as possible (59, to be specific -- certain characters like small caps and glyphs use 2 bytes). I generated very large strings and pared them down just enough to fill the compressed data limit to 100.00% using each character set. I performed 3 trials each, recording how many characters would fit for each encoding type, then averaged these amounts for a general comparison. Results are as follows:
Trial 1
Base64: 15846 characters max.
Hex: 23230 characters max.
Trial 2
Base64: 15776 characters max.
Hex: 23261 characters max.
Trial 3
Base64: 15757 characters max.
Hex: 23275 characters max.
Averages
Base64: 15793 characters max. -- 11,845 bytes
Hex: 23255 characters max.-- 11,628 bytes
From these trials, the difference in byte capacity vs. compressed size appears to be about 2%, which suprised me. While there could be cases in which custom encoding offers various benefits, in general I think I'll stick with hexidecimal. For me, a negligible increase in storage efficiency is more than offset by much easier conversion to and from byte values and some degree of readability.
Join Squirt as he jumps and bounces in the sky through varying times of day, on his way to Cloud Land.
Features character and level animation, 60fps gameplay, over 150 unique screens of platforming, and a simple ending-- all in under 280 characters!
Controls:
Left/Right---Move
Z------------Small bounce
X------------Regular bounce
Z+X----------Super bounce
Reset Cart---Retry
This is the first game I made for Pico-8 (or for any platform, for that matter...). I wasn't originally planning to try and fit a game in this small a size, I was just working on a platformer game test, but then I came across the concept of tweetcarts and things went in an unexpected direction. I planned to upload the release version a long time ago, but wanted to fit a couple more things in.
Hello, first post here.
I just got started with Pico-8 recently, and have learned about the usefulness of storing data in strings to get around token limits. I was wondering, can I build a data string using a p8 program, then output that string as text that can be fed into another p8 program without it being reformatted? I'm working on a graphical level-editor program that will output level data strings usable by another cart.
I tried using printh(), but when I opened the text file it mangled up the extended character glyphs and didn't preserve the 4x3 font lower-case letters I had in the string. My goal is to have all 121 characters available so I can store about 7 bits per character, instead of the 4 possible with hexadecimal, if this is possible.
Thanks.
